Remarks 



By this paper, independent claims 1 & 10 are amended to incorporate the subject matter 
of the respective dependent claims 4, 9 & 13. Specifically, independent claims 1 & 10 are 
amended to specify that the sender of the object initially creates an empty hashtable, integrates 
executable program code into the hashtable, and then serializes the hashtable into a serialized 
hashtable data object for transport to the receiver. Additionally, the independent claims specify 
that data is added to the hashtable by the receiver prior to invoking of the executable program 
code retrieved from the hashtable, with the hashtable as the only data input thereto. Based upon 
these amendments. Applicants respectfully submit that independent claims 1 & 10 patentably 
distinguish over the applied and cited art. Claims 1-3, 5-8, 10-12 & 14-17 remain pending. 

In the final Office Action, claims 1-4, 9-13, 18 & 19 were rejected under 35 U.S.C. 
§ 102(e) as being anticipated by WoUrath et al. (U.S. Patent No. 6,487,607 Bl; hereinafter 
WoUrath); claims 1, 10 & 19 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Bahrs et al. (U.S. Patent No. 6,292,933 Bl; hereinafter Bahrs) in view of Jones et al. (U.S. Patent 
No. 6,629,154 Bl; hereinafter Jones); and claims 5-8, 14-17 & 20 were rejected under 35 U.S.C. 
§103(a) as being unpatentable over WoUrath in view of Skinner etal. (U.S. Patent No. 6,721,740 
B 1 ; hereinafter Skinner). These rejections are respectfiilly traversed to any extent deemed 
applicable to the claims presented herewith, and reconsideration thereof is requested for the 
reasons set forth below. 

Applicants' recited invention is a protocol for transferring executable program code 
between computer processes, along with the data to be input to the executable program code. 
For example, claim 1 recites: 

• providing an object which provides a hashtable, the hastable having at 
least one set of elements, one element of the at least one set of elements 
comprising executable program code, liie providing including: 

• creating an empty hashtable, 

• integrating executable program code into the hashtable, and 

• serializing the hashtable into a serialized data object for transport to 
the receiver computer process, . 

• wherein the executable program code includes logic which employs as 
data input at least one other element of the hashtable. 
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• transferring the object from a sender computer process to a receiver 
computer process, retrieving the executable program code from the 
hashtable and invoking the executable program code with the hashtable 
as the only data input thereto, wherein data is added to the hashtable by 
the receiver prior to invoking of the executable program code retrieved 
from the hashtable, with the hashtable as the only data input thereto. 

Advantageously, within Applicants' recited hashtable, both the executable program code 

and the data input to the logic of the executable program code within the hashtable are provided 

as separate elements. No similar protocol is taught or suggested by WoUrath, Bahrs, Jones or 

Skinner, either alone or in combination. 

Initially, Applicants respectfully submit that the phrase executable program code is a 
well-known term of art meaning program code in an executable format, such as program code 
that has been converted into an executable file by a compiler. Executable program code is 
program code that can be executed or run on a computer, and is distinct from parameters or data 
input employed by the executable program code when executing. The discussion below of 
Applicants' novel protocol relies on these definitions of the phrases employed in the recited 
invention. The rejections to the pending claims are addressed separately below in the order 
raised in the Office Action. 

In rejecting claims 1-4, 9-13, 18 & 19 as anticipated by WoUrath, the Office Action relies 
upon steps 702-710 of FIG. 7, as well as the discussion thereof at coltrnm 10, line 41- column 1 1, 
line 14. In describing FIG. 7, these lines teach: 

FIG. 7 is a flow chart of a process 700 for RMI using generic code not 
specific to any particular type of remote objects on which the method is invoked. 
An application in client machine 601 invokes a method on a stub that is an 
instance of the generic proxy class (step 701). The generic proxy instance's 
"invoke" method is called with the method object and parameter list bundled in 
an object array (step 702). The generic proxy transmits an identifier, which may 
include an object id, method hash and marshals parameter to a server machine 
(step 703). 

Further details on the use of a method hash are disclosed in U.S. patent 
application entitled "Method and System for Deterministic Hashes to Identify 
Remote Methods, " which was previously incorporated herein by reference. 
Marshalling involves consfructing an object from a byte stream including code or 
a reference to code for use in the construction. Marshalling and unmarshalling 
are explained in U.S. Patent application Ser. No. 08/950,756, filed on Oct. 15, 
1997, and entitled "Deferred Reconstruction of Objects and Remote Loading in a 
Distributed System," now allowed, which is incorporated herein by reference, 
(emphases added.) 
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Server machine 606 reads the object id and method hash (step 704), and it 
looks up the method object for the call using the method hash (step 705). Server 
machine 606 unmarshals the parameters for the operation given the types of the 
parameters specified in the method object (step 706). Step 706 may involve 
building a method table, which compiles values for particular methods and is 
initialized when a remove object is created and exported. The generic code 
creates a correspondence between a method hash and a particular method object. 
Thus, by using the hashes in the method table, different skeletons typed to 
different types of objects is not required for method invocation to correspond 
method hash to method object. 

Server machine 606 invokes the method on the remote object implementation 
(step 707), and it marshals the return result(s) to the caller using the return type 
information in the method object (step 708). The generic proxy unmarshals the 
return result(s) using the return type information in the method object (step 709) 
and returns result(s) to the caller, client machine 601 (step 710). 

The above-italicized Application incorporated by reference in WoUrath issued as U.S. 
Patent No. 6,134,603. Additionally, a continuation thereof issued as U.S. Patent No. 6,629,154 
B 1 . The Abstracts of these two incorporated patents provide further details on the use of the 
method hash in the protocol being employed by Wollrath. These Abstracts teach: 

A method and system is provided to uniquely identify a remote method to 
invoke on a server using a hash value computed from the method signature sent 
from the client to the server with the call request. When a client wishes to invoke 
a remote method located on a server, the client sends a hash value identifying the 
remote method to the server in the "remote method invocation" (RMI) call. In 
one implementation, this hash value is created by applying a hash ftinction to the 
method string name and the parameter type list and possibly the return type. 
When the server receives the RMI call, the server identifies which method is 
being called using the received hash value. The server maintains a mapping of 
hash values to their associated remote methods located on the server and 
references the correct method using the hash value. Additionally, in one 
implementation, the server creates the mapping table dynamically when a remove 
object is created. The server identifies the methods implemented by the object 
and creates hash values for each method. These hash values are stored in a 
mapping table which is used to reference the remote methods. 

As expressly taught in the Abstract for these two patents, Wollrath provides a method and 
system to uniquely identify a remote method to invoke on a server using a hash value computed 
from the method signature sent from the client to the server with the call request. When a client 
wishes to invoke a remote method located on a server, the client sends a hash value identifying 
the remote method to the server in the "remote method invocation" (RMI) call. In one 
implementation, the hash value is created by applying a hash function to the method string name 
and the parameter type list and possibly the return type. 
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As clearly taught by the above-cited lines of WoUrath, the WoUrath protocol applies a 
hash function to the method name and parameter type list. The method name is distinct from the 
executable program code itself, and is merely a name for code. In Applicants' invention, the 
executable program code itself is part of the hashtable being transferred from the sender 
computer process to the receiver computer process. Thus, the cited lines of WoUrath actually 
teach away from Applicants' recited invention. For at least this reason, Applicants respectfiiUy 
submit that there is no anticipation of their independent claims based upon WoUrath. 

Additionally, Applicants respectfully submit that the RMI protocols is a well-established 
protocol. In RMI, it is assumed that the method to be invoked is already resident at the remote 
process, i.e., the server. Further, in RMI, the sender and receiver have a knowledge agreement 
as to the methods to be invoked via a registering process. This is in contrast with Applicants' 
recited invention, wherein the executable program code is essentially "pushed" as part of the 
hashtable from the sender computer process to the receiver computer process. No similar 
teaching is provided by WoUrath, or the other art-of-record. 

In summary, WoUrath expressly teaches at column 10, lines 51-54 that details of the 
method h^h are provided in the incorporated patents. These incorporated patents expressly 
teach the creation of a hash from the method signature which is sent from the client to the server. 
There is no teaching or suggestion in WoUrath of transferring within an object a hashtable which 
includes executable program per se. Rather, in WoUrath, RMI protocol is employed which again 
assumes the existence on the server (i.e., the remote process) of the program code (i.e., method) 
to be invoked. Since WoUrath expressly teaches the use of RMI, WoUrath does not anticipate 
Applicants' invention as set forth in the pending independent claims. Each of Applicants' 
independent claims recite that the object being transferred from the sender computer process to 
the receiver computer process includes a hashtable, one element of which is executable program 
code, with one other element of the hashtable being data input to the executable program code. 
Thus, Applicants respectfiiUy request withdrawal of the anticipation rejection to their 
independent claims based upon WoUrath. 

Independent claims 1 & 1 0 presented herewith are amended to more particularly point 
out and distinctly claim the above-noted difference between Applicants' invention and the 
teachings of the applied art. For example. Applicants' independent claims recite that the sender 
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provides the object by creating an empty hashtable and integrating executable program code into 
the hashtable. As noted above, the applied art fails to teach or suggest integration of executable 
program code into the hashtable, wherein executable program code is program code that can be 
executed or run on a computer. 

Additionally, independent claims 1 & 10 presented herewith further recite adding data to 
the hashtable at the receiver computer process prior to invoking of the executable program code 
retrieved from the hashtable. 

Applicants respectfully submit that the careful reading of WoUrath fails to teach or 
suggest this protocol. Cited against these claims is step 706, as well as column 10, line 64 - 
column 11, line 7 of WoUrath. Step 706 in FIG. 7 of Wolhath states: "Server unmarshalls the 
parameters for the operation given the types of parameter specified in the method object." The 
cited lines of column 10 & 1 1 state: 

".. .Server machine 606 unmarshalls the parameters for the operation 
given the types of the parameters specified in the method object (step 706). 
Step 706 may involve building a method table, which compiles values for 
particular methods and is initialized when a remote object is created and 
exported. The generic code creates a correspondence between a method hash 
and a particular method object. Thus, by using the hashes in the method 
table, different skeletons typed to different types of objects is not required for 
method invocation correspond method hash to method object." 

Applicants respectfully submit that the above-noted teachings from WoUrath are not 

relevant to the recited protocol. In Applicants' claims, the recited invention includes adding data 

to the hashtable at the receiver computer process. There is no data taught in step 706 of FIG. 7 

or the accompanying discussion in columns 10 & 1 1 being added to a hashtable received at a 
receiver computer process. As such, the claims are believed patentable over the applied art. 

Still further, the independent claims recite that the executable program code uses as data 
input only the hashtable. Thus, the data input recited in the claims is data provided by the sender 
computer process placed into the hashtable before sending of the object and/or data placed into 
the hashtable by the receiver computer process after receipt of object. Again, there is no similar 
teaching or suggestion in the applied or cited art. For at least the above-noted reasons. 
Applicants respectfully submit that all claims patentably distinguish over the applied and cited 
art. 
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The rejection to independent claims 1 & 10 under 35 U.S.C. § 103(a) as being 
unpatentable over Bahrs in view of Jones is believed moot in view of the amendments presented 
herewith. However, for completeness. Applicants provide the following comments. 

Bahrs describes a method and apparatus for serializing data. A serializer receives a data 
element for serialization, and the data element includes a class-name string. Responsive to 

receiving the data element, the serializer replaces the class-name string with a code having a 
smaller size than the class-name string to form a modified data element. Responsive to forming 
the modified data element, the serializer serializes the modified data element. The serialized data 
element is transmitted and deserialized by a deserializer which replaces the indicator with the 
class name. (See Abstract of Bahrs.) 

Initially, Applicants respectfully submit that Bahrs is not relevant to the invention recited 
herein. Bahrs describes a serializer for serializing a data element. Bahrs teaches that the data 
element includes a class-name string. In Bahrs, the class-name string is replaced with a "code" 
having a smaller size than the class-name string to form a modified data element. Clearly, the 
"code" referred to in Bahrs is an encoded or shortened version of the class-name string. Bahrs 
expressly teaches this in the Abstract where it is stated that the "code" has a smaller size than the 
class-name string and forms a modified data element. Thus, there is no teaching, suggestion or 
implication in Bahrs of an executable program code being included with a hashtable, as recited in 
Applicants' independent claims. To the extent the Office Action asserts otherwise, it is believed 
a mischaracterization of the teachings of Bahrs. 

In the Office Action, colunrn 4, lines 53-63, colimm 60, lines 16-35 & column 66, lines 
34-59 are cited. These cited lines of Bahrs simply provide additional details on the above-noted 
functionality summarized in the Abstract. In Bahrs, a class name is replaced with an indicator 
having a smaller size than the class name to form a modified data element. Claim 2 at column 
66 of Bahrs describes the step of replacing the class-name string with the indicator of smaller 
size. This step includes hashing the class name to create a hash code and replacing the class 
name with a hash code. The phrase "hash code" again refers to an encoded version of the class 
name, and not to executable program code as the phrase as understood by one skilled in the art. 
Since there is no executable program code in Bahrs comprising an element of a hashtable, it is 
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respectfully submitted that Applicants' invention patentably distinguishes over the teachings of 
Bahrs and Jones, alone or in combination. 

Jones describes a method and system for deterministic hashes to identify remote methods. 
When a client wishes to invoke a remote method located on a server, the client sends a hash 
value identifying the remote method to the server in the "remote method invocation" (RMI) 
called. In one implementation, this hash value is created by applying a hash function to a 
method-string name and the parameter type list and possibly return type. When the server 
receives the RMI call, the server identifies which method is being called, using the received hash 
value. (See Abstract of Jones.) 

Since Jones expressly teaches an RMI-based protocol. Applicants respectfully submit that 
Jones does not teach the above-noted deficiencies of Bahrs when applied against the pending 
independent claims. Neither patent teaches Applicants' recited protocol providing an object 
comprising a hashtable, wherein one element of the hashtable is executable program code, and 
another element of the hashtable is data input which is employed by the executable program 
code. Using Applicants' recited object, the executable program code itself, and the data input to 
the code, are both pushed or transferred from a sender computer process to a receiver computer 
process. In both Bahrs and Jones, a remote method invocation call is employed wherein an 
executable program code resident on the receiving computer system is identified by the data 
sending computer system, but not transferred firom the data sending computer system, let alone in 
a hashtable as recited in Applicants' protocol. Combining Jones with Bahrs combines one RMI 
protocol with another RMI protocol. The resultant combination is still an RMI protocol, which 
is distinct from Applicants' recited processing wherein the executable program code itself is 
included as part of the hasthtable forwarded from the sender computer process to the receiver 
computer process, along with the input data employed by the executable program code. No 
similar processing is taught or suggested by the combined RMI protocols of Bahrs and Jones. 
Thus, reconsideration and withdrawal of the rejection based thereon are respectfully requested. 

For at least the above-noted reasons. Applicants respectfully submit that the pending 
independent claims patentably distinguish over the applied art. The dependent claims are 
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believed allowable for the same reasons as the independent claims, as well as for their own 
additional characterizations. 



For example, independent claims 7 & 16 further indicate that the first hashtable received 
fi-om the first sender computer process and the second hashtable received firom the second sender 
computer process are merged at the receiver computer process into a common hashtable. In 
rejecting this subject matter, the Office Action relies upon WoUrath and Skinner. In particular, 
lines 34-51 of Skinner. These lines teach: 

"Serialization provides a useful mechanism for object persistence and 
transmission. With respect to persistence, a serialized object may be stored in 
memory any length of time and regenerated with the same state the object had 
at the time it was serialized. With respect to object transmission, a serialized 
object may be transmitted between remote clients and servers as a data 
streams or packets in accordance with known communication protocols, such 
as the protocol implemented by the Remote. Method Invocator (RMI) API. 
Also, serialized objects may be written to a shared portion of memory by one 
application and read out of the shared memory by another application. 
Client-side and server-side communication management components 305A 
and 305B implement methods to perform serialization and deserialization 
functions. Data transmission and reception of serialized objects, may be 
implemented using any known communication protocol as described above." 

Applicants respectfiilly submit that the above-noted teachings from the Skinner patent are 
simply not relevant to the recited functionality. In Applicants' recited invention, the hashtable 
includes executable program code to be invoked. In Skinner, objects and method calls are 
transmitted between a client and application server. Objects configured with metadata can be 
serialized, i.e. broken down into a set of data bytes and later reconstituted (i.e., deserialized by 
the same or different application) to generate a copy of the original object. It is respectfully 
submitted that this breaking down of objects configured with metadata refers to a data stream, 
not to a hashtable containing executable program code. There is no discussion in Skinner that 
the objects configured with metadata include executable program code within a hashtable. As 
such, Applicants respectfully submit that claims 7 & 16 patentably distinguish over WoUrath and 
Skinner taken together. Further, there is no teaching or suggestion in Skinner of iterating 
through the common hashtable for executable program code to be invoked using the common 
hashtable as the only data input thereto. For at least these reasons. Applicants request 
reconsideration allowance of dependent claims 7 & 16. 
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Dependent claims 8 & 17 are believed allowable for the same reasons noted above respect to 
claims 7 & 16 as well as those reasons stated above respect to dependent claims 4, 13 & 20. 
These dependent claims further recite that the receiver computer process adds data to the 
common hashtable prior to invoking the executable program code using as data input only the 
common hashtable. In the Office Action, Skinner is cited against the subject matter of claims 8 
& 17. In particular, column 16, lines 43-51 discuss serialized objects which may be written to a 
shared portion of memory in one application and read out of the shared memory by another 
application. Client side and server side communication management components implement to 
perform serialization and deserialization fimctions. These teachings are simply not relevant to 
the functionality recited in Applicants' dependent claims 8 & 17. There is no teaching or 
suggestion in Skinner (or in Wollrath) of a receiver computer process adding data to a hashtable 
which is relevant to the received executable program code within the hashtable and which is 
added prior to invoking the executable program code using as data input only the hashtable. As 
such. Applicants respectfully submit that these claims patentably distinguish over the applied art. 

All claims are believed to be in condition for allowance and such action is respectfully 
requested. 

Should any issue remain unresolved, Applicants' undersigned representative requests a 
telephone interview with the Examiner to further discuss the matter in the hope of advancing 
prosecution of the subject application. 



Dated: January i1 , 2008 

HESLIN ROTHENBERG FARLEY & MESITI P.C. 

5 Columbia Circle 
Albany, New York 12203 
Telephone: (518) 452-5600 
Facsimile: (518) 452-5579 



Respectfully submitted, 




Kevin P. Radigan, ^S^. 
Attorney for Applicants 
Reg. No.: 31,789 
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